内部 ALB の HTTPS 通信を試してみた
みなさま Xin chao.
先日、とある AWS 環境の構築作業で、内部 Application Load Balancer (以下 ALB) で HTTPS 通信を行うという話が浮上しました。 インターネット向け ALB の HTTPS 通信については多くのドキュメントや、弊社をはじめとするたくさんのブログが公開されていますが、内部 ALB となるとあまり情報を見つけることができませんでした (単に自分の情報収集能力が低いという可能性もありますが...)。
内部 ALB の HTTPS 通信はどのように設定すればよいのか心配になり、社内の技術 QA を覗いてみると、ちょうど似たようなやり取りが行われていた履歴があったので、そのやり取りを参考に、検証環境を用意して実際に試してみることにしました。
試した環境
内部 ALB 配下に 2 台の Web Server を配置し、別 VPC 内にある踏み台サーバーから 内部 ALB に対し、HTTPS 通信を試してみました。
結論
結論から言うと、インターネット向け ALB と同じ方法で、内部 ALB に対し HTTPS で通信させることができました。
今回試した環境での前提条件は以下の通りです。
- パブリックなドメイン (eg. xxxxxx.classmethod.info) を有している
- そのドメインのホストゾーンに、プライベート IP (eg. 10.0.0.1) を返すレコードセットを登録することを許容できる
非クラウド環境においては、プライベート IP を返すレコードセットを登録することに違和感を覚えることがあるかもしれませんが、AWS においては、内部 ALB に割り当てられる DNS 名を名前解決すると、プライベート IP になっているなど普通に使われているので、問題になることは少ないと思います。
やってみた
Web Server や 踏み台サーバー, 内部 ALB は既に構築済みで、踏み台サーバーから 内部 ALB に対し、内部 ALB の DNS 名 (eg. internal-web-server-intalb-XXXXXXXXX.ap-northeast-1.elb.amazonaws.com) で HTTP 通信ができる状態から始めます。
ブラウザを再読み込みすると、ALB 配下のもう 1 台の EC2 へも接続されます。
内部 ALB なので、DNS 名を名前解決すると、プライベート IP アドレスが表示されます。
レコードセットの作成
今回、ドメインは Route 53 に登録し、内部 ALB に www というホスト名を割り当てます。
[レコードセットの作成] をクリックし、「エイリアス」で "はい" を選択すると、インターネット向け ALB と同じように、「エイリアス先」として内部 ALB を選択することができました。
ACM による証明書の発行
引き続き、AWS Certificate Manager (=ACM) で、パブリック証明書を作成します。
今回は、DNS 検証でリクエストします。
DNS 検証用のレコードを、Route 53 に作成します。
DNS 検証用のレコードが Route 53 に登録されました。
しばらくすると、DNS 検証が行われ、証明書が発行されました。
内部 ALB へのリスナー追加
内部 ALB のリスナーは、現時点では HTTP:80 のみとなっています。
リスナーに HTTPS:443 を追加します。 「デフォルトの SSL 証明書」では、ACM で発行した証明書を選択します。
HTTPS:443 がリスナーに追加されました。
内部 ALB に適用しているセキュリティグループに対し、HTTPS のインバウンドトラフィックを許可します。
動作確認
踏み台サーバーから、ブラウザでアクセスすると、内部 ALB に対し HTTPS で通信できました。
ブラウザを再読み込みし、ALB 配下のもう 1 台の EC2 への接続も確認できました。
名前解決すると、内部 ALB の DNS 名と同じプライベート IP アドレスが表示され、www が内部 ALB を指していることが分かります。
まとめ
パブリックなドメインを保有していて、そのレコードセットにプライベート IP を返すレコードを登録することを NG としなければ、インターネット向け ALB と同じ手順で、内部 ALB に対して HTTPS 通信を行うことができました。 内部 Classic Load Balancer についても、同じ手順で HTTPS 通信が可能です。
そもそも内部 ALB への通信に、HTTPS 化が必要なのかという議論はあると思いますが、AWS 環境に VPN / Direct Connect 接続を行っている組織内ネットワークの盗聴から通信内容を守りたい、組織のポリシーによって通信の暗号化が要求されているといった場合には、HTTPS 化は有効だと思います。
ALB ～ EC2 間も HTTPS 通信させたい場合は、以下の弊社ブログが参考になります。
![[Auth0] Route 53+ACM+CloudFrontでAuth0にカスタムドメインとリバースプロキシを設定してみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-e37cf03c5caac969de0f633e4738977d/1862834d1806cb03b64a8000a5a1a39e/Auth0ByOkta.jpg)
